Public key infrastructure (PKI) decryption and verification capabilities are built into commercially available browsers such as Netscape Navigator™ and Microsoft Internet Explorer™. Microsoft Authenticode™ is a prior art system for securing the distribution of program code over the Internet which uses PKI (see “Software Publisher Digital IDs for Microsoft Authenticode Technology” at http://www.verisign.com/rsc/gd/dev/authenticode/intro.html). The functioning of Microsoft Authenticode™ will be discussed in detail below with reference to FIG. 1.
FIG. 1 is a schematic diagram of the prior art system used by Microsoft Authenticode™ for distributing executable code. The diagram shows three main parties: a publisher 100 an end user 300 and a certificate authority 200. To publish software over the Internet using Microsoft Authenticode™, publisher 100 must first apply to certificate authority 200 for a private and public key pair and for a certificate. Certificate authorities, such as Verisign Inc., are in the business of providing private and public key pairs to receiving parties. Moreover, they are responsible for checking the bona fides of their receiving parties and for providing digital certificates which may be provided as proof that the public key belongs to the receiving party and not a third party. On successful application, publisher 100 is provided with a private key 102 and a certificate 104 by certificate authority 200. Certificate 104 contains the name 106 of the publisher, a public key 108 provided to the publisher and a digital signature 110 from certificate authority 200 computed over both name 106 and public key 108. Certificate authority 200 generates digital signature 110 using its own private key 202, of which the corresponding public key 204 is made widely available to end users by being pre-installed in browsers such as Netscape Navigator™ and Microsoft Internet Explorer™. This digital signature 110 serves to confirm that public key 108 contained in certificate 104 belongs to publisher 100. For a detailed explanation of certificate authorities and digital certificates see “Internet Cryptography” by Richard E. Smith, 1997, published by Addison Wesley Longman, Inc., in particular chapter 12.
Having developed software 112, publisher 100 encrypts the software using his/her private key 102 to generate an encrypted version 114. Unencrypted software 112, encrypted software 114 and certificate 104 are then bundled together to form a package 116. This package is made available for downloading by placing it on a web server 118. End user 300, who downloads package 116 from web server 118, is able to authenticate software 112 as follows. Pre-installed in the end user's browser is public key 204 belonging to certificate authority 200. Using this, the end user is able to confirm that public key 108 contained in certificate 104 belongs to publisher 100. This is because the browser is able to decrypt digital signature 110 using public key 204 and compare the result with name 106 and public key 108 and because certificate 104 was signed by certificate authority 200, which the browser trusts. Using public key 108 obtained from certificate 104, the browser is able to decrypt encrypted version 114 of software 112 and compare it to the unencrypted version of the software also provided. If the two match, the browser knows that software 112 originates from publisher 100 and, furthermore, that it has not been modified since being encrypted. Thus, end user 300 is able to authenticate the source and integrity of software 112.
One disadvantage with the approach taken by Microsoft Authenticode™ is that it does not offer security from the program code provider directly—i.e. it does not allow the program code provider to act as a sole certificate authority or a low level certificate authority within a hierarchical certification system (see below for an explanation of these terms). One result of this disadvantage is that it does not allow the program code provider to arrange a level of security appropriate for its own purposes, the type of program code provided or the requirements of its receiving parties. A further result is that it does not engender trust of the program code provider directly since the authentication process appears to the receiving party to bear no relation to the program code provider but rather to Microsoft™.
N Islam et al ‘A Flexible Security Model for Using Internet Content’ IBM Thomas J. Watson Research Center Publication, 28 Jun. 1997, XP 002138803 describes a system for downloading content over an untrusted network, such as the Internet, and for controlling its use on a client device, content is stamped using digital signatures and analysed by a stamped content usage system to verify the identity of the creator of the content and to verify that it has not been modified.
The present invention addresses in general the security problems of providing content over the Internet identified above as well as the particular disadvantages of the approach taken by Microsoft Authenticode™ identified above. One objective of the present invention is to provide an easy to use system for providing verifiable content over a public data network such as the Internet. A further or alternate objective of the present invention is to provide a system for the provision of a news service over a public data network such as the Internet.